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ABSTRAfTT 

As expert systems become more widely used, their access to large amounts of external information 
becomes increasingly important. This information exists in several forms such as statistics, tabular data, 
knowledge gained by experts and large databases of information maintained by companies. Because 
many expert systems, including CLIPS, do not provide access to this external information, much of the 
usefulness of expert systems is left untapped. The scope of this paper is to describe a database 
extension for the CLIPS expert system ahelL 

The current industry standard database language is SQL. Due to SQL standardization, large amounts 
of information stored on various computers, potentially at different locations, will be more easily 
accessible. Expert systems should be able to directly access these existing databases rather than 
requiring information to be re-entered into the expert system environment. The ORACLE relational 
database management system (RDBMS) was used to provide a database connection within the CUPS 
environment. 

To facilitate relational database access, a query generation system was developed as a CLIPS user- 
function. The queries are entered in a CLIPS-like syntax and are passed to the query generator, which 
constructs and submits for execution, an SQL query to the ORACLE RDBMS. The query results are 
asserted as CLIPS facts. 

The query generator was developed primarily for use within the ICADS project (Intelligent Computer 
Aided Design System) currently being developed fay the CAD Research Unit in the California 
Polytechnic State University (Cal Poly). In ICADS, there are several parallel or distributed expert 
systems accessing a common knowledge base of facta. Each expert system has a narrow domain of 
interest and therefore needs only certain portions of the information. The query generator provides a 
common method of accessing this information and allows the expert system to specify what data is 
needed without specifying how to retrieve it. 


Dr. Laurian Chiriea is a Professor of Computer Science; James Snyder is a student in the Computer 
Science Department at the California Polytechnic State University, San Luis Obispo, California. 
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INTRODUCTION 

Currently, Cal Poly’s CAD Research Unit is developing an Intelligent Computer Aided Design System 
(I CADS). This system is composed of several domain expert systems ru nn i ng concurrently under the 
control of a blackboard [Pohl, Myers, Chapman, Cotton, 1989]. The current application area under 
development is architecture, but the system’s applicability can be easily extended to other daciplinee. 
In order for the domain expert systems to evaluate a design, a large amount of information needs to 
be available to the expert systems. This body of information does not remain static and therefore needs 
a management system. In addition, there are two major classes of information needed by an expert 
system. - reference infor mati on and prototype information. Reference information can be described as 
tabular information such as a parts catalog. Each part has an identifier, a description, and a price. 
Another example of reference information is thermal lag times for various construction materials. 

Prototype information comes from a knowledge representation scheme called Prototypical Information 
[Gero, Maher, Zhang , 1988]. A prototype describes the general characteristics that most objects have. 
For example, the ICADS project uses a Building Type Prototype Database. This database stores 
information about typical high-rise apartments. Some of the kinds of information stored are: owner 
goals «nd objectives, user group profiles, and designer criteria. 

Prototypical information has a very complex structure unlike reference information. Complex retrieval 
methods are necessary for cer tain information and application programmers should not be concerned 
with the details of retrieving information. Not only is prototype and reference information needed 
within expert systems, but it is needed in other environments as well, such as C programs. Because 
common information is needed in disjoint environments, a common storage me chanis m is needed, 
namely a Data Base Management System (DBMS). A DBMS provides a recoverable and concurrent 
method of storage and retrieval of data. These features are very necessary within the ICADS project 
because there are many independent expert systems executing, all of which could access the database. 
Figure 1 shows the ICADS system architecture and how expert systems, which we refer to as Intelligent 
Design Tools (IDT), need access to database information. 

The current DBMS of choice is the Relational DBMS (RDBMS). Because of its simplicity and power, 
it has become the DBMS standard. RDBMSs use a Fourth Generation Lan gu ag e (4GL) or query 
language to perform operations on database objects [Korth, Silberschatz, 1986]. The de facto standard 
4GL is the Structured Query Language (SQL). This query language is available on most hardware 
platforms and operating systems from PCs to super-computers. 


PRAm.KM DEFINITION AND REQ 




The ICADS project uses CLIPS as its expert system shell, which in its standard version does not 
support RDBMS access. Because an RDBMS provides a common storage and retrieval method, we 
decided r elational database access within CLIPS was necessary. The solution had several general 
requirements which needed to be met to be useful. They were: 


To allow the use of the standard RDBMS features. 

To be easy for the expert system developer to use. 

To allow for easy integration into the CLIPS source code. 
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The CLIPS acces s system needed to allow for most of the database queries possible. Figure 2 

fllu ffo wte ft general form of an SQL query. Hie SEUSCT danse defines the par ticular attributes to 
be retrieved. For example, the description of a part would be listed in this clause. The FROM clause 
defines which database relations the information is to come from. In this scheme, data can come from 
multiple relations in a single query. A user retrieves only the information needed from each r ela tio n . 

The W HERE clause defines constraints under which data is retrieved. For exam ple, only the employees 
in department 10 should be considered. In addition, the WHERE clause can contain a join condition 
which tells the database system that a join between two or more relations needs to be executed. For 
example, an attribute of each employee is the department number they belong to. You want a list of 
all employees and the name of the department they work in. This information is not co n tain e d in one 
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(getsql queryl employee . name department . name 
= employee .d_no department . d_no 
= department . d_no 1 0 

) 


figure 4 - Sample CLIPS SQL query 


addition, row from the database that is returned is prefixed with the user’s query label and 
asserted as CUPS fact by a C function provided by CUPS. 

The tr anslati on from the CUP S syntax to SQL is very natural. The SELECT clause is obtained from 
the < column-list > previously defined The FROM clause is obtained by building a list of relation 
names from the < column-list > relation names. The WHERE clause is obtained from the < condition- 
list > d efin ed above. The operator and the first value are inverted to conform to the SQL syntax. The 
ORDER BY clause is implicitly built by the < column-list > . The data will be sorted based on the order 
in which the columns w e re listed 


SAMPLE APPLICATIONS 
The Attribute Loader 

In I CADS, the Attribute Loader is a special expert system which reads information from the database 
and asserts it into the semantic network. The I CADS project uses a frame-based representation to store 
information within its expert s y s tem s [PohL, Myers, Chapman, Cotton, 1989]. The primary function 
of the Attribute Loader is to read the information from the database, ass emb le frames and assert them 
as facts. 

The information is obtained from the ICADS Prototype Database, which contains information about 
typical b uilding types **nd typical site locations. The structure of the prototype database is shown in 
Figure 4. The boxed items repr es e n t base relations; the circles represent relationship relations between 
base relations. Currently, objects, attributes, and values are retrieved from the d atabas e and asserted 
The query generator allows the expert system source to remain constant even if a new database 
management system is used 

DBEESOLVE 

Bec ause we use frame-based knowledge, expert systems have frames as p a t t er ns in rules. Some frames 
rmn be quite complicated md wm typographic errors. To increase programmer productivity, 

we created a program which resolves frames in an expert system with the information contained within 
the d«**h««* The DBRESOLVE programs function is very similar to a cross-referencing tool but is 
applied to frames. 

The DBRESOLVE program the expert system source and identifies the occurrences of frame 

information which needs to be verified This information is then checked against the database 
information. Any frames which are not contained in the database are flagged as incorrect. 
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place. It resides in two relations: employees and departments. A join condition specifies that the 
employee' 8 department number must match a departme n t nu mb er in the department r elat i o n. 

The ORDER BY clause sorts the data in a specific ordering. If this clause is not specified, the data is 
returned in a system-dependent order which may not remain constant over time. 


SELECT 

<lis t 

of 

FROM 

<list 

of 

WHERE 

<list 

of 

ORDER BY 

<list 

of 


column names> 
relation names> 
boolean conditions> 
columns names> 


Figure 2 - General form of an SQL query 


From the point of view of an expert system developer, the database a c ces s should be intuitive and easy 
to use. The ideal solution would allow the user to specify the desired information in a CLTPS-Hke 
syntax. This considerably reduces the learning curve of the database access system. 

Placing the djitah ase access system within the CLIPS environment should be as simple as add i ng any 
other user-defined CLIPS function. The database access system should be as sma ll and fast as possible. 


AN SQL QUERY GENER ATOR VCfil HLIPS 

Our solution to the above problem was to develop a query generator for CLIPS. The function of the 
query generator is to take a CLIPS database query within a rule, translate it into SQL and submit the 
query for execution. The results of the query are then asserted as CLIPS facts. 

The implementation of the query generator can be divided into three areas! the CUP S interface syntax, 
the SQL interface, and the tr anslati on process. The general CUPS syntax is defined in Figure 3. A 
< label > defines a unique label to prefix the facts when they are asserted. A < column-list > is a list 
of columns prefixed with a relation name to eliminate any ambiguous references to col umns . For 
example, two diff erent relations may have a column named "description” . Here must be a way to 
differentiate between mliiTrm, so they are prefixed with their relation names. A < condition^list > 
is a relational operator followed by constants or column names. 


(getsql <label> <column-list> <condition-li8t>) 

Figure 8 - General CLIPS • SQL syntax 


Figure 4 shows a complete example. The query label is "query 1". Hie employee names and department 
numbers from department 10 wfil be asserted as facts. Notice the join condition between the employee 
and department relations. 

The SQL interface is invisible to a CLIPS user. The interface pertains only to the RDBMS that is used. 
In the IGADS system, we used the Embedded SQL option which allows C programs to submit queries 
for execution [Korth, Sflberschatz, 1986]. Embedded SQL naturally falls in line with CUP S, which is 
also written in C. We designed the system to take any SQL query and submit it for execution. In 
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Figure 5 - Prototype Database Structure 


CONCLUSIONS 

Our initial hopes for de c r ease d development time were easily met. Because of system’s simplici ty, 
queries ^ be easily written. Using a RDBMS allows the ap plicat ion programmer to onfy retrieve 
the information they need, which is better than storing info rma ti on in hard coded facts or reading 
information from disk files. In addition, other environments can access the same information. 

Initially, we had concerns that query times would be too large. This proved to be quite the opposite. 
Becau se of the buffer management of the RDBMS, many queries execute faster t han if the same 
information were read from a disk file. 

Per haps th e most important feature of firing a RDBMS is the concurrency, integrity and reusability of 
Ant* in many orthogonal environments. Within ICADS, many programs and expert systems arress the 
same relatio ns . If any of the dwt* within a relation changes, every system which accesses it retrieves 
the current and c o rrectly updated values. Concurrency and integrity control would be extremely 
complicated to add to CLIPS, but it comes automatically by using a RDBMS. 

The above factors mak e an RDBMS a superior method of information storage and retrieval We have 
not yet encountered any drawbacks to using this approach. 


431 








BIBLIOGRAPHY 


[Gero, Mahe-, Zbm y 1988] GercvL, M. Maher and W. Zhang; ’Chunking Structural Design Knowledge 
as Prototypes’; Working Paper, Architectural Computing Unit, Department of Architectural Science, 
U niversi ty of Sydney, Australia, January, 1988. 

{Korth and BBbermdmt* 1986] Korth ELF. and A. SDberachalz; Database System Concepts’; McGraw- 
Hill, 1986. 

[Pohl, Myers, rh^pmim , Cotton 1989] Pohl, J., L. Myers, A Chapm a n , J. Cotton; 1CADS: Working 
Model Version 1’; Technical Report, CADBU-03-89, CAD Research Unit, Design Institute, Cal Poly, San 
Luis Obispo, Calif., USA, December, 1989. 


432 



